The rate at which wireless networks are being deployed is accelerating along with their size and ubiquity. While enterprises, carriers, government and municipalities rush to deploy wireless networks, evolving technological standards, and inadequacies in current wireless products (such as lack of flexibility, scalability, and mobility features) render challenges in the deployment of wireless networks.
Wireless networks based on 802.11/WiFi and 802.16/WiMax technology standards comprise a majority of current wireless deployments. Wireless access to wired networks and the Internet is provided by radio devices deployed at the edge of the network. New wireless networks are being deployed in locations where associating a wireless access point (AP) are not located near wired networks. These networks are being created from access points that interact together to form a mesh of nodes, denoted as wireless mesh.
These wireless mesh networks may be standalone or may link to a wired network at an access point. One or many wireless mesh networks may be linked together via a wireless links or via wired networks. The wireless mesh networks may be secure encrypting data between wireless access points. An Access Pointing (AP) operating as part of a mesh is denoted as a mesh point (MP). PRIOR ART FIG. 1 shows the access points 100, 101, 102, 103, 104, 105 and 106 operating as a Mesh Point. Mesh Point 104 is connected to a wired switch (107) with an Authentication Server (108) attached to it. Mesh Point 105 is connected to a wired switch (109) with a Captive portal attached to it (110).
The new wireless networks are intended to support varied applications including, as examples, security cameras, voice calls, sensors and support of traditional computing. These applications are supported over access points with a range of bandwidth with limited power resources. To support these applications, there is a need for wireless mesh nodes need to create forwarding paths based on MAC addresses that support:                Quality of Service (QoS) tuned for a particular application such as voice, video, sensor network,        802.11e forwarding for QoS paths,        Unicast data traffic,        Multicast data traffic,        Traffic loading based on bandwidth on radio link,        Power usage of a particular wireless mesh,        Resource constraints for Radio Frequency (Channel, radio, power, antenna), Power or Environment, or        Connectivity to wired network or to Authentication server, or        Multiple links to the wired network, and        Different levels of security for different paths.        
Some of the applications running over a wireless network have stringent requirements end-to-end delay, network convergence time, fast fail-over to alternate paths and congestion avoidance. For example, voice requires fast fail-over time between pathways so that voice calls will not be dropped. Traditional networks may utilize pre-calculated fail-over paths for voice calls based on relatively stable network topologies. Radio interference in radio medium can cause frequent topology changes requiring either on-demand calculation of network topologies or frequent re-calculation of end-to-end fail-over paths. These features are not supported by the prior art.
There is also a need for path algorithms that allow fast network convergence times on the order of milliseconds; this is particularly critical for radio networks, especially the mesh networks. Calculating these forwarding paths can be done via a path calculation algorithm or user policy or a combination of user policy and path calculation. Path calculation algorithms include distance vector algorithms, path vector algorithms, link-state protocols, or link-state path vector algorithms. User policies aid in creating logical networks whose performance may be tuned for QoS for applications such as voice, video or data, different traffic patterns for unicast and multicast, reducing power usage in a wireless mesh and upholding different security levels. Combining both forwarding path calculation and policy places additional constraints on path calculation algorithms, and there is a need to resolve these constraints and provide expedited calculation of forwarding paths in mesh networks.
Routing protocols that are not adapted to run over radio networks may not calculate efficient or stable pathways. The radio network has limited bandwidth on the radio transmission, potential periods of radio signal degradation, and potential interference between transmissions of data. Thus, in view of the Limited bandwidth in mesh networks, there is a need for multiple pathways between two mesh points in order to provide load sharing across the network.
Links between the wired network and the wireless mesh, may occur at any mesh point. Policy and bandwidth may require that certain pathways to the wired network are preferred over others. Thus, there is a need to augment forwarding path calculations to allow policies or path calculation metrics to favor pathway to the wired networks over another. Wired links may be preferred due to bandwidth or due to their access to captive portals or Authentication servers.
Links between two wireless mesh networks may also occur, but the interconnection needs to be governed by unique policy. Using 802.11s additions to 802.11, the wireless mesh will have unique identification code. Two wireless meshes may interconnect at any, some or all nodes (PRIOR ART FIG. 3 gives an example of two mesh networks interconnected.) Forwarding path calculation need to differentiate between intra-mesh networks and inter-mesh networks or mesh networks and wired. Existing path calculations do not allow these considerations in the pathway calculations.
Traditional MAC level forwarding uses broadcast of multicast frames. The broadcast of these multicast frames may send frames to switches that do not have receivers for that multicast group. In traditional Local Area Networks (LANs) formed by Ethernet, this overhead of transmitting frames that will be discarded is not burdensome. In the radio environment with limited bandwidth, the extra transmission limits the capacity of the full system. Specific multicast distribution paths are needed to tailor forwarding paths to just the access points that must receive the information. Algorithms that calculate these multicast paths need to operate without heavy calculation overhead when the mesh network topologies change frequently due to interference in the radio domain.
Mesh networks may be of a small size (32 nodes or less) specified by 802.11s or grow to larger networks. The path calculation needs to support scalable growth with as the mesh expands by:                Numbers of mesh points in the mesh,        Numbers of radio physical and logical links between nodes,        Numbers of Stations associated with each mesh point that in turn may be accessed by the network, and        Numbers of MAC level multicast groups.        
To summarize, traditional path calculation algorithms need to be augment to support the wireless mesh by existing paths and user policy regarding:                Supporting alternate paths based on MAC addresses based on any application QoS, 802.11e QoS,        Unicast or multicast traffic or traffic loading on links,        Resource constraints (power, RF frequency)        Connectivity to wired networks, other mesh networks,        Existence of security services (Captive portal or Authentication portal),        Levels of security, and        Existence of particular individual MAC or groups of MAC addresses.        Existing path calculation algorithms do not support all these factors within the path calculation for a mesh network.Secure Pathways in Mesh Point Networks        
Securing the data traffic that transverses a wireless mesh network via the air medium entails encryption of data traffic. In existing wireless networks with access points attached to switches (either local MACs or split MAC), the Authentication Server (AS) distributes keys to client stations associated an access point. Each station—access point has a pair-wise key. All stations from a particular access point share group key for broadcast data.
In a mesh network, traffic that flows between access points may be encrypted. To encrypt this traffic, each mesh point encrypts data. A mesh point has a pair-wise key for each remote mesh point to which it transmits data. In addition, each mesh point has a single key to encrypt broadcast information sent to all mesh points in its radio range. The mesh point with stations associated has the following keys:                Pair-wise key with each remote station,        Group key for all stations associated with mesh point,        Pair-wise key with each remote Mesh Point exchanging traffic with, and        Group key for transmission of data to all Mesh Points within radio range.        
In deployments where security of a video stream or other multicast data needs to have a higher security than the general group key, an alternate group key for specific data transmission is desirable for this node. In the on-demand multicast group, the data between a set of mesh points may be encrypted using an alternate set of group keys from the mesh point's general group key. This alternate short-term group key for a mesh point may encrypt all data or data from a specific station associated with the node. The routing infrastructure exchanges an indication that these new group keys are requested; in this may be facilitated by either passing around a Group MAC address or passing an indicator that the node would like to use alternate group keys for all of its data. Traffic Encrypted with the new group need should only flow when both a multicast path and the encryption keys have been set-up at all stations and mesh-points supporting the on-demand secure multicast traffic flow. Thus, the path calculation (also called mesh routing infrastructure) must pass two indicators to start the on-demand secure pathways: 1) a mesh point desires set-up an on-demand multicast keys and 2) the mesh point has completed set-up of on-demand multicast keys. To terminate the on-demand secure pathways, the routing infrastructure needs to indicate that: 1) mesh point no longer desires that on-demand flow path, and 2) that the multicast on-demand secure pathways have been terminated.
As a non-limiting example, three stations want to share a secure on-demand multicast group is shown in PRIOR ART FIG. 2. Station 1 (201) wants to have an on-demand multicast forwarding path that does not share the node group keys with the existing broadcast keys when sending Group traffic to Group MAC address 1. As station 1 (201) transmits data to a Secure Group MAC address (80:00:01:01:01:01), policy on Mesh Point 1 (204) triggers the set-up of a secure multicast path to any other listeners. At the same point station 2 (202) and station 3 (203) request via higher level protocols (GMRP or proprietary protocols) to Mesh Point 2 (205) and Mesh Point 3 (206) that they are interested in receiving traffic for Secure Group 1 MAC address (80:00:01:01:01:01). Both of these mesh points utilize the routing infrastructure to pass an indication that an on-demand secure key needs to be set-up for group traffic transmitted between mesh points 1, 2 and 3 (204, 205, 206). Mesh Point 4 (207) does not desire to have the on-demand group key and retains its original group key.
Mesh Point 1 obtains a secure multicast key from the Authentication server to itself. Mesh Points 2 and 3 also obtain a new group key from the Authentication server for on-demand secure group. Once the keys are received, the path calculation algorithms calculate a specific multicast tree for the on-demand secure keys.
At some point in the future, Station 1 finishes sending its secure data and wishes to return to the use of the general node multicast key. Station 1 (201) has several ways of signaling this to Mesh Point 1 (204). As a non-limiting example, the mesh point can detect that no traffic has been sent for a period of time. At this point, the mesh point 1 (204) can signal to the rest of the mesh that the on-demand mesh point is no longer desired and that the path has been terminated. Mesh Point 2 and Mesh Point 3 can also decide based on a variety of mechanisms that they wish to stop receiving multicast traffic from the on-demand group.
Very Secure multicast data transmission of frames may require on-demand securing of a multicast group for a particular set of nodes. A military application that uses “Triple Plan” (Video, Voice and Data) sent to a multicast group may need on-demand security for voice only, video only, and data only or for all voice, video and data. An on-demand group encryption key per node may be required for a higher level of security. These and other limitations and inadequacies in the prior art are addressed by the present invention.